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Disclaimer 


Regtech Adoption Practice Guide is a publication published by the Hong Kong Monetary Authority (HKMA). It should 
be noted that the sole purpose of this publication is to provide Authorized Institutions (banks) with information on the 
latest regulatory technology (Regtech) developments. The HKMA does not endorse any use cases, solutions and/or 
implementation guidance described in this adoption practice guide. If a bank intends to adopt a particular solution 
or implementation, it should undertake its own due diligence to ensure that the technology or approach is suitable 
for its circumstances. 
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1.1 Background 


The value of Regtech in banking is coming to the fore in 
Hong Kong, offering clear benefits to banks, customers, 
and regulators. In November 2020, the HKMA released 
a two-year roadmap to promote Regtech adoption 
in Hong Kong, as laid out in a White Paper titled 
“Transforming Risk Management and Compliance: 
Harnessing the Power of Regtech”.' The White Paper 
identified 16 recommendations across five core areas 
to accelerate the further adoption of Regtech in Hong 
Kong. 


The White Paper acknowledges that since 2019, the HKMA 
published a series of “Regtech Watch” newsletters, 
introducing banks to Regtech use cases on the adoption 
of innovative technology to enhance risk management 
and regulatory compliance. The banks interviewed for 
the White Paper cited these newsletters as a valuable 
source of information and guidance, especially the actual 
or potential Regtech use cases that have been rolled out or 
are being explored in Hong Kong or globally. 


OCUCTION 


The White Paper identified 26 specific application areas 
of Regtech that can benefit banks. There are significant 
opportunities and a strong desire from the industry for the 
HKMA to develop and issue “Regtech Adoption Practice 
Guides” around these application areas. 


As a successor, this Regtech Adoption Practice Guide 
(Guide) series builds on the “Regtech Watch” newsletters 
to include common industry challenges, guidance on 
implementation and examples of what others have done 
successfully to overcome adoption barriers. The Guides are 
to supplement other ongoing HKMA initiatives such as the 
Banking Made Easy initiative, Fintech Supervisory Sandbox 
and the Fintech Supervisory Chatroom. Ultimately, the 
Guides should enhance the sharing of experience related 
to Regtech implementation in the industry, which will help 
further drive Regtech adoption in Hong Kong. 


Regtech solutions have emerged to improve the 
effectiveness and efficiency of risk management and 
compliance activities through harnessing new technologies 


' Transforming Risk Management and Compliance: Harnessing the Power of Regtech, HKMA (November 2020), https://www.hkma.gov.hk/media/eng/doc/key-information/press- 


release/2020/20201102e3a1.pdf 


such as Cloud, Artificial Intelligence, and Blockchain. 
This fourth Guide of the series focuses on “Regulatory 
Reporting and Stress Testing”. As regulators increase 
their use of advanced data analytics to support the 
application of supervisory technology, 


the frequency and granularity of regulatory reporting 


advanced 
requirements are increasing generally. Stress testing, 
which is often linked to regulatory reporting, also poses 
challenges as it requires the precise collation of detailed 
data to support the application of stress test scenarios 
defined by the regulators.* In both cases, institutions are 
often faced with the challenge of having to extract data 
from multiple source systems (which were often designed 
and implemented before the latest regulatory reporting or 
stress testing requirements became effective) and then 
adjust or enhance the data to ensure it meets the specific 
requirements of the relevant regulatory report or stress 
test scenario. The current processes adopted by banks 
often place heavy reliance on manual data manipulation 
and checking, which increases the amount of time and 
costs needed to produce the required reports. Manual 
processes or controls increase the likelihood that errors 
in the data could remain undetected and carry over into 
This Guide 
introduces implementation guidance on Regtech solutions 


the information provided to the regulators. 


aimed at alleviating some of the pain points related to 
Regulatory Reporting and Stress Testing. 


1.2 Purpose 


The purpose of this Guide is to provide an overview of 
Regtech solutions on Regulatory Reporting and Stress 
Testing, outline the common challenges observed 
regarding Regtech adoption, and share information on 
how others have addressed the challenges to successfully 
adopt Regtech solutions on Regulatory Reporting and 
Stress Testing in their organisations. This Guide follows 
the outline below: 
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1 Explain how Regtech solutions can be used to 
support Regulatory Reporting and Stress Testing 


e Outline the key challenges that banks in Hong Kong 
are facing in this area 


e |llustrate the benefits of leveraging Regtech 
solutions for Regulatory Reporting and Stress 
Testing 


e Describe the key considerations when adopting 
Regtech solutions for Regulatory Reporting and 
Stress Testing 


2 Provide practical implementation guidelines to 


banks on the adoption of Regtech solutions for 
Regulatory Reporting and Stress Testing 


e Outline the key implementation components for 
Regulatory Reporting and Stress Testing Regtech 
solutions 


3 Share use cases on the adoption of Regtech 


solutions for Regulatory Reporting and Stress 
Testing 


e Describe the challenges faced by a bank and 
how the Regtech solution helped to resolve these 
challenges 


e Outline the key success factors from successful 
Regtech implementation, from the bank and/or the 
Regtech provider's perspectives 


? Transforming Risk Management and Compliance: Harnessing the Power of Regtech, HKMA (November 2020), https://www.hkma.gov.hk/media/eng/doc/key-information/press- 


release/2020/20201102e3a1.pdf 
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2.1 Key challenges/ 
developments 


Regulatory reporting fulfils an important function, 
providing supervisors with the essential information they 
need to monitor banks’ business activities, and financial 
and operational risk exposure. The data requested by 
regulators needs to meet precise specifications, and is 
often produced in accordance with detailed completion 
instructions. Errors in regulatory reporting can cause 
significant problems for the institution, in the most serious 
cases resulting in fines and penalties. 


Stress testing is a technique to assess and analyse a 
bank's potential vulnerability (e.g. profitability, liquidity, and 
capital adequacy) to stressed conditions, and the process 
can be resource intensive. Technology solutions are often 
underpinned by an Economic Scenario Generator module 
that generates values for an array of parameters, simulating 
potential stress test scenarios. This is then applied to 
the specific financial circumstances of the institution to 
project its business over a period of time. This equips 
management and regulators with a better understanding 
of the financial risks faced by the business and enables 
banks to make informed strategic decisions that balance 
profitability, liquidity, and capital adequacy. 


Increasing granularity and 
frequency of Regulatory Reporting 
and Stress Testing requirements 


e Regulatory reporting involves the submission of raw or 
formatted data - prudential returns, for example — as 
required by regulators to evaluate and track the financial 
and operational status and compliance of the institution. 


e The trend towards higher granularity and frequency for 
both local and overseas reporting requirements is a key 
challenge for banks. This trend is driven by regulators 
requiring more granular data from the institutions they 
supervise in order to facilitate their adoption of greater 
technology and advanced data analytics, which in turn 
allows regulators to increase the effectiveness of their 
supervision. 


e Institutions are expected to be able to run bank-wide 
and risk-specific stress tests with a shorter turnaround 
time in order to assess the stress impacts under ad-hoc 
scenarios, for example, the COVID-19 pandemic. This 
imposes higher requirements on institutions’ stress 
testing frameworks and data flows to encourage further 
streamlined processes, minimal manual effort, and a 
higher degree of automation. 


Significant effort required to 
implement changes and maintain 
ongoing monitoring processes for 
Regulatory Reporting and Stress 
Testing 


Related to the above challenge is the increasing effort 
required by institutions to implement changes to meet 
more granular and frequent reporting requirements. 


Every time a regulatory report changes, or a new stress 
test scenario is introduced, institutions need to analyse 
the new data requirements and determine the most 
effective way to extract and format the information to 
meet the new requirements. 


Banks’ source systems were often designed before 
new regulatory requirements or stress tests were 
introduced, resulting in a need to pull data from multiple 
source systems and enrich or adjust the data to ensure 
it contains all the attributes needed to accurately and 
correctly populate the regulatory report or complete the 
required stress test. 


Transparency is required to 
facilitate reviews by internal 
control functions and external 
auditors 


As Regulatory Reporting and Stress Testing 
requirements are updated over time, the transparency 
of data sources, requirement specifications, and any 
adjustments or enhancements to the supporting tools 
are becoming increasingly important. 


Without the appropriate level of transparency, internal 
control functions within institutions or external parties 
such as auditors or regulators’ examination teams are 
unable to gain sufficient evidence to support opinions 
on the completeness and accuracy of data presented in 
the end reports provided to regulators. 


The ability to clearly identify and explain any adjustments 
made to the source data is particularly critical and is 
often difficult, particularly in cases where there is a 
heavy reliance on manual adjustments, or when data is 
combined from multiple sources. 


Model documentation and related model validation 
supporting documentation have become a more 
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important part of the independent assessment carried 
out by internal auditors and/or regulators. 


Key-person risk resulting 
from manual processes and 
adjustments 


The reliance on manual processes and adjustments 
to support existing Regulatory Reporting and Stress 
Testing can often result in key-person risk, particularly 
for the smaller branches or subsidiaries of overseas 
banks which may not maintain large finance or reporting 
functions in every location in which they operate. 


Under these circumstances, the absence or resignation 
of a key team member can not only create difficulties 
for the future production of regulatory reports or stress 
tests, but it can also result in the loss of “institutional 
knowledge” concerning the rationale and methodologies 
adopted for adjustments made to previous reporting. 


In certain circumstances, it may be difficult for 
institutions to provide adequate responses to enquiries 
from regulators when the key individuals responsible 
for the report or stress test production are no longer 
available. 


Difficulties in scaling existing 
processes to support business 
expansion 


As banks expand both the scope and scale of their 
business operations, they may find it difficult to support 
business growth using existing manual processes and 
controls over Regulatory Reporting and Stress Testing. 


Adding additional people to Regulatory Reporting and 
Stress Testing teams to support increased volumes or 
new reports required due to additional product lines is 
not only costly, but can also be challenging given talent 
shortages for experienced candidates in the market. 


Institutions have developed numerous processes to 
cater to the new regulatory requirements post the 
2007-2009 global financial crisis. Due to resource 
constraints and tight timelines during these exercises, 
institutions often had to develop quick solutions to 
fulfil regulators’ expectations. These solutions often 
lack flexibility increasing the effort required to compile 
reports for regulators or for business needs. 


8| Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing 


Increased expectations for 2.1.1 Specific challenges 
management accountability and developments related to 


e Regulators have emphasised in recent years the regulatory reporting 
accountability of senior management at banks across all 
areas of conduct and regulatory compliance, including 
regulatory reporting. 


Manual approval process: Regulatory reporting generally 
features complicated approval processes that are 
predominantly manual with lengthy paper trails. The 
approval process is required to ensure that the report fulfils 
requirements and detects potential problems with the 
dataset. The approval process often involves numerous 
iterations and levels of approval, including technical staff, 
experienced financial experts, programmers, and finally 


e Regulatory Reporting and Stress Testing processes 
need to have robust internal controls linked to key 
performance indicators (KPIs) and key risk indicators 
(KRIs) to facilitate oversight and supervision by those 
accountable. 


management review. This resource-intensive process is 
prone to errors resulting from a high degree of human 
involvement. The highly manual approval process can 
also divert the focus of operational staff away from value- 
adding activities, and can make the whole process a costly 
exercise. 


e It can often be difficult to facilitate such accountability 
and oversight where processes and related controls are 
highly manual in nature. 






LLITS 


Compliance across jurisdictions: Each jurisdiction has its 
own reporting formats that require banks to customise each 
report to fulfil the different requirements from respective 
regulators. Banks therefore need to dedicate significant 
time and effort to getting a holistic view of all regulatory 
reporting requirements, especially across jurisdictions. 
This is particularly challenging as these requirements are 
updated from time to time, and some requirements need 
the bank to provide detailed data in a specific format (e.g. 
securities transactions). 


Data quality and completeness: Traditionally, banks store 
their data that they extract from various places in multiple 
data sources. The siloed data structure within different 
systems results in a lack of end-to-end traceability of the 
data, and the data held can often vary in terms of quality. 
As a result, banks need to put more effort into verifying and 
reconciling the data between different data sources. 
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Key development - Granular Data Repository (GDR): 
The HKMA's GDR pilot to collect more granular data is 
ongoing, with selected participating banks submitting 
data to a broad reporting data grid. Once this initiative 
eventually becomes a reporting requirement, banks can 
consider Regtech solutions to help, as manual processes 
may not be cost-effective and efficient to comply with 
these requirements. 


2.1.2 Key stress testing 
challenges and developments 


Increased regulatory demand for stress testing: Over 
the past few years, there has been an increasing demand 
from regulators for banks to perform different stress tests. 
In Hong Kong, stress test scenarios are required to reflect 
all major types of risks faced by a bank, including credit, 
market, liquidity, interest rate, strategic, operational, legal, 
and reputation risks.° In order to perform stress tests on all 


3 Supervisory Policy Manual - Stress-testing (!C-5), HKMA, https://www.hkma.gov.hk/media/eng/doc/key-functions/banking-stability/supervisory-policy-manual/IC-5.pdf 
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the related areas, banks need to extract large amounts of 
data and allocate significant resources to perform the tests. 
As a result, banks often prioritise stress tests that are 
intended to meet regulatory reporting requirements above 
other stress tests which are not regulatory requirements, 
but may be equally useful and beneficial in the early 
identification of risks and supporting business decision- 
making. 


Lack of standardised processes and framework: A 
significant challenge observed is that the stress testing 
process is not repeatable at scale. This results in more 
time and resources required to execute different stress test 
scenarios as banks do not have standardised processes 
and frameworks to aggregate the data needed to perform 
the tests. Traditionally, banks have a siloed data structure, 
and the data utilised to generate stress test scenarios is 
segregated between different business units and core 
Each business unit owner develops their own 
stress test scenarios individually with varying frequency, 
with some stress tests being run monthly, quarterly, or 
annually, and others only as required as part of a regulator- 
driven stress test. Given the lack of coordination and a 
platform that aggregates all of the data to a single source, 
banks often spend a lot of time and effort in compiling 
individual stress tests, and also find it difficult to meet 
both internal stakeholders’ and regulators’ expectations 
on the time needed to collate the required data and run 
the stress tests. In addition, many banks do not have a 
centralised scenario generation engine, which often results 
in inconsistent stress test scenarios being applied. 


systems. 


Insufficient consideration of business implications: 
Banks perform stress tests mainly for regulatory compliance 
purposes. However, the stress test exercise should be 
more risk and business sensitive. Both the quantitative 
and qualitative measures should be tailored based on 
banks’ business and customer profiles as well as their 
risk appetite. Appropriate attribution analysis should be 
performed to identify the bank's main risk and capital 
drivers. Ultimately, the goal of stress testing is beyond 
compliance: it is to drive meaningful business strategies in 
order to improve the bank's overall risk profile and optimise 
the balance sheet. 


Key development — Climate Risk: Regulators around the 
world, including the HKMA, are inviting/requesting banks 
to conduct stress tests on the impact of climate risk on 
their overall risk profile. In particular, there is a focus on 
implications for credit risk where borrowers either hold 
assets that could be subject to damage (resulting in financial 


losses) from the impact of climate change (known as 
“ohysical risk") as well as borrowers whose industries are 
subject to significant changes (e.g. adjustment towards a 
lower-carbon economy) that could impact their profitability 
(known as “transition risk"). These new climate risk 
stress tests invite institutions to develop and implement 
new methodologies that are designed to measure the 
impact of physical and transition risk across an extended 
time period. In addition to the challenge arising from the 
need to implement new models and methodologies, banks 
are also finding that the new climate risk stress tests 
can put significant strain on their existing data sources. 
For example, information about a borrower's underlying 
business such as the industry in which they operate is key 
for the accurate modelling of transition risk, but existing 
customer industry data may not provide sufficient accuracy 
such as in cases where a borrower has exposures across 
multiple industries. 


2.2 How can Regulatory 
Reporting and Stress Testing 
Regtech solutions help? 


2.2.1 Regulatory reporting 


Gathering source data 


Regtech solutions can help streamline and better control 
the gathering of source data from different systems 
across the bank. By automating the process of extracting, 
transforming, and loading (ETL) data into the regulatory 
reporting solution, banks can save time and effort, while 
eliminating or significantly reducing the risk of human error, 
therefore increasing data quality. Moreover, the application 
of technology in this area can help banks establish an 
audited and automated decision process flow to increase 
the visibility and traceability of the data. 


Key capabilities that Regtech solutions can provide to 
automate and better control the data gathering process 
include the ability to: 


e easily enrich or add data from different source systems 
while maintaining a transparent audit trail; 


e manage data according to predefined rules which can 
be aligned to regulators’ completion instructions and 
easily reviewed/updated as the requirements change; 


e automate the data loading and normalisation process 
with built-in checks to detect any anomalies and flag 
them to the appropriate managers; and 


e facilitate the ingestion of different data files and formats 
into the reporting solution including spreadsheets, text 
files, different types/formats of database, as well as 
structured and unstructured data from external sources 
such as data vendors and regulators’ websites. 


Rather than maintaining the data in individual silos, Regtech 
solutions can provide a single aggregated database sourced 
from multiple internal and external systems in different 
jurisdictions. Data can be uploaded to this repository on 
a real-time basis and system alerts can be generated if 
any anomalies or changes above certain thresholds are 
detected. Data management tools can be integrated 
into the solution to facilitate management reporting and 
oversight on the accuracy and completeness of the data 
that is being fed into the regulatory reporting process. 
Regulatory reporting solutions are usually equipped with a 
notification system that will automatically alert management 
if issues are identified in the data or processes, providing 
the ability to discover issues at an early stage. 


Report generation 


Regtech solutions can greatly simplify and speed up 
the report generation process, ensuring that templates 
provided by regulators are accurately and quickly populated 
with the data matching the precise specifications in the 
relevant completion instructions. 


There are often complex computations embedded within 
the regulatory reports, in areas such as: 


e Risk-weighted asset computations for market risk and 
credit risk exposures 


e Operational risk measures 


e Liquidity risk ratios, such as the liquidity coverage ratio 
(LCR) or liquidity maintenance ratio (LMR) 


e Funding measures such as the net stable funding ratio 
(NSFR) or core funding ratio (CFR) 


e Leverage ratio 


e Large exposure and connected counterparty reporting 
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Regtech solutions can be used to automate these 
computations ensuring they are calculated accurately in 
accordance with the regulatory requirements. Regtech 
solutions can also be used to facilitate the real-time 
monitoring of compliance with the key thresholds or 
regulatory minimums for these ratios. It also allows early 
warning indicators and thresholds to be set, which would 
alert management on a timely basis of any fluctuations 
that could indicate increased risk of a potential future 
compliance breach. 


The process of generating the reports for submission can 
itself be automated through built-in scheduling capabilities 
which enable the Regtech solution to define and manage 
regular batch jobs whereby the generated reports are 
automatically provided to report owners for review and 
approval ahead of the reporting deadline. 


Regtech solutions can also significantly reduce the 
workload associated with report generation for banks that 
have a presence in multiple regions, and therefore need 
to submit multiple reports according to each regulator's 
requirements and specifications. To keep track of multiple 
reporting requirements, Regtech solutions often provide 
a dashboard to store and track reports generated for all 
applicable jurisdictions. 


Regtech solutions can also significantly reduce the 
workload associated with changes to regulatory reporting 
templates. Many of these solutions are provided to banks 
with a commitment that whenever regulators change their 
report templates or specifications, the Regtech solution 
will be updated by the vendor accordingly. This helps to 
relieve some of the time and effort needed by banks to 
deal with changes to regulatory reporting requirements. 
However, banks would still need to work with the solution 
provider to ensure that the mapping of data to the solution 
is appropriate for the change. 


Furthermore, many regulatory reporting solutions not 
only provide banks with the necessary tools to generate 
regulatory reports, but they also facilitate easier creation of 
bespoke reports that can be used for internal management 
reporting purposes. Third-party end-user report writing and 
query tools are also often supported. 


Report analysis and validation 


When a report is generated, banks need to review 
and analyse the data presented in the report. Senior 


management responsible for signing off on the report needs 
to be comfortable that the report is complete and accurate. 
Regtech solutions provide tools to support report analysis 
and validation. 


One such tool allows individual returns 





to re-run multiple times during the production process to 
ensure there are no errors resulting from incorrect batch 
uploads into the database. The tool analyses the trend and 
variance of individual cells (in the report) that are useful for 
management reporting, and tracks each change and action 
made by the reviewer to the report, including additional 
comments and documents added by the reviewer. Data 
Drilldown features allow users to click a cell and gain 
immediate insights into the different supporting datasets. 


Full audit functionality permits user IDs, dates, and times 
of any adjustments to be captured and stored for future 
reference. 


Another tool is a set of validation rules which are pre-set by 
the solution provider to match the requirements set by the 
regulator in the completion instructions. These validation 
rules ensure that no report can be approved for release 
unless it satisfies all the mandatory checks required by the 
regulator or implied by the completion instructions. If a 
validation check fails, the solution will provide details of the 
Regtech 
solutions also often contain a feature which allows banks 


precise cells which violate the validation rules. 


to define and enforce their own report validation rules. 


In addition, regulatory usually 
incorporate report visualisation tools which allow banks 


reporting solutions 


to track trends across reports and identify any outliers 
that could indicate underlying problems in the report 
datasets, or business trends which should be brought to 
management's attention. Some solutions also allow users 
to add their own commentary to record the explanations 
for key variances alongside documents which evidence the 
investigation performed to support the explanation. This 
can be particularly useful when responding to regulators’ 
or auditors’ queries. 


Report submission 


Before banks can officially submit a report to the regulators, 
a group of reviewers are responsible for performing a final 
review to ensure the report fulfils all the requirements. 
Regtech solutions can help streamline the report submission 
process. For example, the solutions can facilitate a robust 
approval process by establishing a hierarchy of reviewers, 
improving accountability. The solution normally features 
a dashboard that provides an overview of all items that 
require the reviewer's action, and assigns the tasks 
to relevant owners as well as a comprehensive return 
completion report that captures all of the major features 
of the return together with comments, adjustments, 
variances, and attachments. Finally, Regtech solutions can 
automate the uploading process of the reviewed report to 
the regulator’s submission platform. 
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To further help banks with their future report submissions, 
some regulatory reporting solutions support the analysis of 
reports that are returned by the regulators for amendment, 
recording the feedback and changes made to the report 
which can be used as reference for improved future report 
generation. 


2.2.2 Stress testing 


Given that stress testing Itself is often linked to regulatory 
reporting (either for internal purposes or for the regulator), 
stress testing Regtech solutions can bring many of the 
same advantages as the regulatory reporting Regtech 
solutions to banks. 


Scenario generation 


Regtech can help banks create a centralised data source 
including bank-specific and market data. It has been 
observed that stress testing models share a large base of 
underlying data from banks’ transactional and customer 
data. Centralising data sources can significantly reduce the 
amount of effort spent on data aggregation, cleansing, and 
transformation, providing a higher degree of synergy. In 
addition, developing a central scenario generation engine 
can leverage a single source of market data and establish 
a set of bank-wide scenarios to be applied consistently 
across different stress test scenarios. Regtech solutions 
can also often adopt a more complex modelling approach to 
better incorporate interdependencies/correlations between 
macroeconomic factors. 


Stress testing workflow and integration 


Stress tests often have a high degree of interrelation. 
For example, market risk-specific stress tests can be 
leveraged for bank-wide stress testing. A bank-wide stress 
testing workflow can facilitate the standardisation of the 
stress testing process, identify the dependent models and 
aggregate the stress test results. An efficient workflow 
tool can also help track the lifecycle of various stress tests, 
and enable banks to coordinate and streamline bank-wide 
stress testing. 


Stress testing model management 


Stress Testing involves a large set of models and tools, 
A technology-based 
model management tool can assist banks with managing 


as well as qualitative judgement. 


a comprehensive inventory of models/tools and relevant 
supporting documentation. This will provide an audit 
trail for internal/external assessments. For further model 
enhancements for internal purposes or regulatory updates, 
a centralised and complete model inventory will also help 
holistically assess the relevant impacts. 
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Report modelling 


The input from stress tests can help shape and supplement 
the information needed to create a regulatory report. Some 
key features of Regtech solutions include various modelling 
techniques to analyse collected data, the ability to project 
economic scenarios/financial positions, and to estimate the 
impact of different scenarios on the institution's balance 
sheets and profit. The solutions also help collect data from 
past stress events, assess their impact on banks at the 
time, and measure how they might impact a bank if they 
were to happen again. 


For banks that do not have a framework in place, relevant 
Regtech solutions help banks set a standardised data 
and process framework to simplify the Stress Testing 
process. Having a set framework reduces the effort 
needed for banks to customise each process for specific 
test scenarios. The solution also helps with aggregating all 
the data required for all stress tests into one single source, 
ensuring that the data required for test scenarios share 
the same database. Consequently, banks can easily know 
what data is available and can avoid extracting the same 
sets of data into the database, creating duplications which 
can distort stress test results. With these features, banks 
can generate hypothetical stress test scenarios that are 
realistic and provide a more accurate indication of how the 
market is likely to perform and the resulting impact on the 
bank's exposure. 





2.3 Key considerations 
when adopting Regulatory 
Reporting and Stress Testing 
Regtech solutions 


The Regtech solutions may help banks, especially 
domestic systemically important banks, fulfil the regulatory 
expectations on risk data aggregation and risk reporting 
under the “Principles for effective risk data aggregation 
and risk reporting”* issued by the Basel Committee on 
Banking Supervision in January 2013, as well as regulatory 
reporting requirements. While implementing Regtech 
solutions can reduce costs and alleviate the resourcing 
burden, banks need to prepare adequately to integrate 
the solution into their operating model. People, skills, and 
processes need to be realigned to support the effective 
use of Regtech solutions. This is particularly important 
for Regulatory Reporting and Stress Testing as incorrect 
implementation or operation of a Regtech solution could 
lead to inaccurate regulatory reporting, or stress tests which 
under- or over-estimate the risks faced by the bank under 
stressed scenarios, leading to compliance breaches and/ 
or inappropriate risk management and business decisions. 


4 Principles for effective risk data aggregation and risk reporting, Basel Committee on Banking Supervision (January 2013), http://www.bis.org/publ/pcbs239.pdf 





Below are some key considerations that banks should be 


aware of before adopting Regtech solutions to help with 
regulatory reporting and/or stress testing: 


Governance and oversight of the Regtech solution: 
Without appropriate governance and oversight, the 
Regtech solution may be used incorrectly resulting 
in inaccurate or incomplete reporting. The proposed 
solution should be evaluated against any applicable 
regulatory requirements (e.g. outsourcing requirements). 
If the proposed solution is Cloud-based, then additional 
controls such as those around cybersecurity should 
be considered (readers can refer to Regtech Adoption 
Practice Guide Issue #1 on Cloud-based Regtech 
solutions® to see more guidance on Cloud security). 
Banks should also ensure that adequate consideration 
is given to protecting and maintaining the confidentiality 
of client information as some regulatory returns or 
stress tests may contain sensitive information. Given 
the critical nature of Regulatory Reporting and Stress 
Testing, adequate contingency arrangements should 
be in place to ensure that reports can be compiled and 
submitted and stress tests can be conducted in the 
event that the primary regulatory reporting system is no 
longer available. 


Data quality and integrity: This is one of the biggest 
challenges for banks looking to adopt a regulatory 
reporting solution. Failure to properly identify all the 
data sources required to ensure accurate reporting, 
identify the data owners, cleanse the data, and integrate 
it into the data model within the Regtech solution can 
result in inaccurate or incomplete reporting. It is also 
important to consider the impact of any changes made 
to datasets on downstream systems used for other 


purposes within the bank. 


Assess the solution's ability to support reporting for 
all applicable jurisdictions: Not all Regtech solutions 
are able to support reports required by all regulators. 
A solution may not cover all the required fields or 
calculations, and may need to be combined with other 
solutions or manual workarounds in order to ensure that 
the bank is able to meet all of its reporting or stress 
testing obligations. 
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Ongoing support and maintenance of the Regtech 
solution: 


— Report automation eliminates a lot of manual 

operational effort. However, banks need to be 
aware that they, or together with the vendor, will 
need to maintain and update the Regtech solution 
(e.g. adding extra reporting fields and creating new 
report templates, etc.) according to changes in 


regulatory requirements. 


— Banks also need to pay attention to the upstream 
regulatory reporting 
requirements which will require strong change 


impact of changes in 


management processes. For example, a new 
requirement to add the ‘sales location’ of a trade 
may require change management on the trade 
capture process, so that the trader knows to input 
the required details at the trade capture stage. 


— Given that some Regtech providers are located 
overseas, there is a risk of inadequate technical 
support for Hong Kong-based clients. 

Culture: Banks could face cultural resistance to 
technology implementation as people tend to be more 
comfortable working in their old ways, or are fearful that 
the technology will replace their jobs. To ensure that 
the solution returns maximum value for banks, culture 
and change management need to be considered and 
implemented. 


5 Regtech Adoption Practice Guide Issue #1: Cloud-based Regtech solutions, HKMA (June 2021), https://www.hkma.gov.hk/media/eng/doc/key-information/press-release/2021/20210617e5a1.pdf 
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Regulatory Reporting and Stress Testing Regtech 
solutions can provide many benefits, but careful 
consideration must be given to the implementation of 
such a business critical solution to avoid any negative 
impacts. 


3.1 Strategy and governance 


3.1.1 Regulatory Reporting and 
Stress Testing strategy 


Banks need to be clear on the objectives and outcomes of 
their Regulatory Reporting and Stress Testing functions. 
This depends on a number of factors that are unique to 
each bank, including the company vision, the company size, 
number and location of operational centres, governance 
structure, existing maturity on enterprise architecture, and 
internal resource capabilities. 


Three example stages are listed below to help institutions 
assess their current Regulatory Reporting and Stress 
Testing maturity: 


Stage 1: The adoption of traditional manual processes to 
fulfil Regulatory Reporting and Stress Testing obligations. 
Regulatory Reporting and Stress Testing is performed 
solely for the purpose of meeting compliance obligations 
and is not aligned to business benefits. 


e Example: Full reliance on end-to-end manual processes 
and controls (operational and compliance team) to 
produce regulatory reports. 


e Example: Data used to generate stress test is still 
siloed and not shared between each stress test scenario 
(including regulator mandated and business-led stress 
test scenarios). 


Stage 2: The adoption of Regtech solutions to fulfil certain 
Regulatory Reporting and Stress Testing obligations. 
Regulatory Reporting and Stress Testing brings some 
business benefits but they cannot be formally measured/ 
quantified. 


e Example: Regtech solutions help automate data 
gathering from different sources to generate a report. 
The compliance team only needs to review the result, 
sign off, and manually send to the applicable regulator. 


e Example: Reverse stress testing® is possible but only 
with significant effort and with little diagnostic support. 
This means that it is difficult to investigate sources of 
potential failure or enable proactive risk assessment 
and implementation of the most appropriate strategy 
for risk monitoring, prevention, and mitigation. 


Stage 3: Extensive and integrated use of Regtech solutions 
across multiple business units to manage the enterprise's 
Regulatory Reporting and Stress Testing. The results of 
the tests provide input for business strategy and are not 
limited to regulatory compliance. Regulatory Reporting and 
Stress Testing are aligned with the business strategy and 
deliver business benefits, with measurable outcomes and 
continuous improvements. 


e Example: A single centralised database that houses the 
data required for all Regulatory Reporting and Stress 
Testing needs. 


e Example: Enterprise-wide regulatory reporting 
procedure is in place and consistent across each 
business area. The reporting solution has a built-in 
capability to design and run ad hoc reports which can 
be used to identify key trends and support business 
decisions. 


e Example: Reverse stress testing is fully supported 
by Regtech solutions including diagnostic support for 
the reverse stress test. This means that it is possible 
to quickly investigate sources of potential failure and 
enable proactive risk assessment and implementation 
of the most appropriate strategy for risk monitoring, 
prevention, and mitigation. 


3.1.2 Governance and common 
framework 


Regulatory Reporting and Stress Testing Regtech 
implementation should not be a one-time effort. Banks 
should establish a sustainable and robust governance 
framework to maintain a regular exercise of fulfilling new 
and changes to reporting and stress testing requirements. 
Key elements to include in Regtech implementation 
projects are: 
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e Determine project milestones, key success factors, 
project timelines, and implement mechanisms to 
monitor and report on progress 


e Ensure appropriate oversight from senior management 
and/or board 


e Involve all relevant functions and departments 


e Consider forming a steering committee 


e Define ownership of both the process and the 
Regtech solution to ensure oversight of the operating 
effectiveness of the solution 


e Identify the skills gaps and strategic partners to work 
with 


e Assess capabilities in skills, expertise, and capacity 
of key resources during implementation and post- 
implementation for the ongoing maintenance and tuning 
of the solution 


The Regulatory Reporting and Stress Testing function 
should be an active stakeholder in a bank's digital 
It is important to ensure that any 
changes to the group system involve considerations of all 


transformation group. 


applicable regulatory reporting requirements at the start of 
the programme, and that these requirements are built into 
the system. 


3.1.3 Organisation and culture 


Regtech solutions can automate a large portion of the 
Regulatory Reporting and Stress Testing function. For 
a solution to be fully adopted and accepted by relevant 
team members, banks need to ensure that the functions 
and benefits of the new solution are properly explained to 
the impacted teams within the organisation. To empower 
employees, analysts can be trained to use the solution’s 
more advanced features to enhance the insights they 
generate, thereby increasing the value that the Regulatory 
Reporting and Stress Testing teams can bring to the bank. 


€ Reverse Stress Test is a stress test that starts with the identification of a pre-defined outcome. Reverse stress-testing identifies scenarios that would lead to a bank's business model becoming 
non-viable (i.e. these are “default” or resolution scenarios). https://www.hkma.gov.hk/media/eng/doc/key-functions/banking-stability/supervisory-policy-manual/|C-5.pdf 
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3.2 Implementation 
considerations 


3.2.1 Data preparation 
Identify the data 


e Establish a streamlined data acquisition and 
transformation process to create a centralised “verified” 
source of data for Regulatory Reporting and Stress 
Testing 


e Build an inventory of key data sources and map them 
to data owners. This can be done through a series of 
focused data ownership workshops 


e Use automated solutions to perform a data lineage 
review that includes the capture and documentation of 
data flows from source systems to the final destination 
in the regulatory report or stress test. This will help 
identify any issues or blockages which could impact 
the accuracy of regulatory reports or stress tests. 
However, banks should note that the performance 
of a data lineage solution may vary depending on the 
complexity of the bank's overall application architecture, 
and the effort required to set up the solution should not 
be underestimated 


e Perform a risk assessment to identify the most critical 
data elements and trace these back to the original data 
source and owner to ensure appropriate controls over 
data quality are in place 


Transform the data 


e Adopt standardised data specifications across different 
databases where feasible 


e Implement an ETL tool to automate data collection and 
processing 


e Identify the key regulatory data items and address any 
issues at the data source level, through enterprise- 
wide data remediation projects, including implementing 
ongoing data quality monitoring and documenting data 
lineage 


Documentation 

e Standardise documentation of data 
specifications, and any adjustments or enhancements 
to aid internal control functions or external parties 


SOUICES, 





such as auditors or regulators’ examination teams to 
gain sufficient evidence to support opinions on the 
completeness and accuracy of data presented in the 
end reports 


3.2.2 Digitalisation and 
Automation 


Solution procurement 


Banks should consider and compare the costs and benefits 
of off-the-shelf solutions, bespoke solutions, and in-house 
development and delivery, or a combination of off-the-shelf 
and in-house development. In particular, banks should pay 
attention to the following areas when conducting the cost- 
benefit analysis: 


e Assess the solution's ability to support reporting for all 
applicable jurisdictions 


e Assess the ongoing support and maintenance model 
offered by the Regtech solution, and ensure an adequate 
in-house support team is in place to bridge any gaps: 


— Assess the timeframe and method of support 
offered by the vendor in response to changes in 
regulatory reporting rules, determine if in-house 
legal, compliance, business analysts, and testers 
are required to respond, and the required resources 
and approach to respond to changes in regulatory 
reporting rules 


- Assess the Service Level Agreement (SLA) of 
technical support offered by the vendor, and the 
location of support to prepare for in-house technical 
support coverage 


Solution development and deployment 


To begin their Regtech journey, banks can consider 
replacing manual processes and controls by embedding 
automation into the Regulatory Reporting and Stress 
Testing processes. This can be done through the use of 
Robotic Process Automation (RPA) and low-code’ platform 
workflow tools that are easy to implement to automate 
manual processes currently performed on spreadsheets. 
A sample RPA implementation framework is presented in 
Figure 1 below to assist with automation implementation. 


Some actions that banks can consider in order to digitalise 
and automate their Regulatory Reporting and Stress 
Testing processes are: 


7 Low-code platforms allow for application development through graphical user interfaces and configuration instead of traditional manual programming. (Source: KPMG) 


e Perform an end-to-end review of Regulatory Reporting 
and Stress Testing processes, identifying relevant 
process owners and understanding the activities they 
perform 


e Identify manual processes that involve repetitive 
execution of standard data cleansing techniques (such 
as reformatting data fields or tagging data with reporting 
codes) 


e Utilise a pilot process orchestration tool that supports 
the identification of process variation, which helps drive 
efficiency/standardisation through increased visibility 
and less reliance on spreadsheets 


e Build an inventory of all stress tests conducted across 
the bank and standardise the data collection templates 
and processes where possible to facilitate the adoption 
of RPA techniques 


Figure 1 - Sample RPA implementation framework 
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Standardise and attempt to centralise processes across 
different product groups and business lines prior to 
implementing RPA solutions 


Assess the readiness of existing systems to interface 
with the solution 


Develop the necessary capabilities to support solution 
deployment 


Fully document the RPA techniques adopted in order to 
facilitate testing at a later stage by internal and external 
stakeholders 


Consider parallel testing of a solution with an existing 
solution to ensure effectiveness 


Perform periodic testing to ensure that the automated 
processes and controls are operating as designed 


Automatically generate impact analysis on new changes 
to operations and policies 





Requirements; 


Automation Assessment 
and Functional 
Requirements Documents; 


Process Complexity 
Assessment and Effort 
Estimation; 


Technical Feasibility and 
Final Effort Estimation; 


BC - Business Case 
creation and approval; 


High Level Roadmap; 
Project Kick-off Meeting; 





a 





Deep-dive into the current 
Process and Systems to 
gain understanding on as-is 
state; 


Process Flow and Process 
Design Document (PDD) 
creation; 


Development Strategy; 
Infrastructure Design; 


Business and Technical 
Design Validation and 
Signoff; 


Detailed Project Plan; 
Environment readiness; 


Acceptance Criteria 
mapped; 





Source: KPMG 


In the instance where a bank already automates most of its 
processes, it can further improve the Regulatory Reporting 
and Stress Testing process by implementing a strategic end- 
to-end solution (i.e. a solution that supports the processes 
of extracting input data, preforming regulatory mapping/ 

















- Establish Development 


Milestones; 
ntermediary Code Review; 


RPA demonstration for 
Business; 


Final Code Review; 


User Acceptance Testing 
(UAT) 


ssue updated Process Flow 
and PDD; 


Create Process Design 
nstruction document; 


Create Instructions for 
release to Production 
document; 





Production Environment 
Setup and Testing; 





Go/No Go Decision; 


calculations, generating regulatory returns and producing 
management information reporting for analysis), while 
keeping in mind that the solution needs to be scalable and 


flexible to cater to regulatory and business changes. 





* Hypercare - War Room for 
live monitoring; 


* Countdown and 
Acceptance Criteria 
Validation; 


+ Developer to support 
operations handover 
meeting 


+ Supporting documents 
final versions (Process 
Flow and PDD); 


* Project Team Offboarding; 











e Change Request; 







* Defect reporting; 


e Incident reporting; 


As part of the Regtech solution's implementation, it is 
critical that adequate contingency arrangements are in 
place to ensure reports can be compiled and submitted and 
stress tests can be carried out in the event that the primary 
regulatory reporting system is no longer available. 
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4.1 Use case #1 — Regulatory 
reporting solution for a virtual 
bank 


4.1.1 Challenge 


A newly established virtual bank in Hong Kong needed to 
adopt a Regulatory Reporting and Stress Testing solution 
that was aligned to its business model, maximising the 
use of technology to minimise manual effort and automate 
related processes and controls. The specific challenge 
it faced was that the virtual bank needed to implement a 
regulatory reporting process that was scalable given the 
planned future growth of the business. A traditional manual 
regulatory reporting process or solution for compiling the 
regulatory returns would have required further investment 
or development later on as the size of the virtual bank grew 
and its product range expanded. In addition, the bank also 
needed to be able to generate stress testing results on a 
timely basis with minimal manual work and intervention. 


WF Kegtech USE Cases 


4.1.2 Approach 


In order to adopt the most efficient and effective regulatory 
reporting process which is scalable to the future growth 
and product expansion of the virtual bank, it chose to 
adopt a Regulatory Reporting and Stress Testing Regtech 
solution and fully integrate it with the virtual bank's core 
banking system, thereby minimising manual steps required 
to produce the regulatory returns or stress test reports. 


4.1.3 Key success factors 


e A regulatory reporting Regtech solution was identified 
which had an established track record of adoption by 
banks in Hong Kong to meet local regulatory reporting 
requirements. This meant that: 


— All the relevant reporting templates were fully 
integrated into the chosen reporting solution 


— The bank was able to hire local regulatory reporting 
team members with previous experience in using 
this kind of solution 


e When the virtual bank implemented the Regtech 
solution, one of the key first steps was to conduct a 
series of workshops to identify ownership of source 
data within the organisation. The chosen Regtech 
vendor worked with the newly hired finance and 
regulatory reporting teams to identify the key data 
points within the bank's core banking system. Early 
decisions on the key data to be extracted and the 
source systems in which it was captured were 
essential to avoid additional effort at a later stage to 
reconfigure the reporting solution. 


e Full integration of the Regulatory Reporting 
and Stress Testing solution with the upstream 
core banking system was necessary to ensure 
the completeness, accuracy and efficiency of the 
regulatory reporting process. Dependencies on other 
workstreams within the overall project to establish the 
virtual bank meant that it was not feasible to complete 
this integration in time for the commencement of 
business. Rather than proceeding with a sub-optimal 
deployment of the Regtech solution, manual reporting 
templates were used until the Regulatory Reporting 
and Stress Testing Regtech solution could be fully 
integrated with the upstream core banking system. 


e Since the virtual bank had not yet commenced business, 
it did not have any data that could be used for UAT of 
the chosen reporting solution. With the lack of data for 
UAT, the bank prepared dummy data which simulated 
expected products and balances in the first year of 
operations. UAT was performed using the dummy 
data to ensure that the regulatory reporting system 
was appropriately configured prior to go-live. 


4.2 Use case #2 - Climate risk 
stress testing 


4.2.1 Challenge 


Climate risk stress testing is a fast-emerging topic in the 
It also has become an area of global 
regulatory focus for the banking industry. Institutions are 


financial market. 


still exploring different approaches to conduct climate risk 
stress testing, and a consensus in terms of methodology 
has not yet been formed. The recently implemented 
climate risk stress test requires the stress impact from all 


traditional risk types (e.g. credit risk and market risk) to be 
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consolidated. A bank in Hong Kong faced the challenge 
of consolidating a large amount of data from different 
sources (both internal data on the Bank's exposures as well 
as external data on different industries and locations) and 
applying a brand new set of stress test scenarios with a 
much longer horizon and a more complex risk identification 
scheme that includes both physical and transition risks. In 
order to overcome this challenge, this bank chose to adopt 
a Regtech solution to collect the data and then leverage 
big data analytics capabilities to develop the stress test 
scenarios. 


4.2.2 Approach 


The bank engaged a consultant with subject matter 
expertise in stress testing and in particular the emerging 
climate risk stress testing area, along with technology 
capabilities to co-develop a Regtech solution that meets 
regulatory requirements and suits the bank's internal 
systems and processes. 


e The first step was for the project team to define and 
separate physical and transition risks. 


e As climate risk stress testing is an emerging area, 
data collection has been largely manual and undefined. 
The project team leveraged big data and Artificial 
Intelligence to identify non-linear relationships between 
different factors and considerations relating to extreme 
weather and other potential consequences of climate 
change. Specifically, the project team used machine 
learning which was trained using a Tensor Processing 
Unit (TPU)®. This enabled assessment on the areas that 
are exposed to a higher risk for flooding based on their 
elevation and geographic location. This analysis would 
not have been possible if traditional regression models 
were used. 


e Next, the project team defined the scope, measures, 
and approach based on the identified key risk factors. 
Credit risk has been identified as the largest driver under 
climate risk stress test scenarios’. Taking physical risk 
as an example, collateral value loss is believed to be 
one of the major factors that increases the expected 
credit loss from real estate loans. Subsequently, loss 
given default for real estate loans was selected to be 
one of the modelling measures to quantify the potential 
collateral value loss. 


® TPU is an Artificial Intelligence accelerator application-specific integrated circuit (ASIC) developed specifically for neural network machine learning, which can accelerate the computation 
performance of machine learning applications and minimise the large and complex machine learning models’ training time. 


3 KPMG market insight 
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The solution then enabled the aggregation of the 
potential loss and capital impact from each of the risk 
types, focusing on the three pillar 1 risks (i.e. credit risk, 
market risk, and operational risk) under each climate risk 
stress test scenario. 


A scenario simulation engine was then developed 
within the Regtech solution to generate scenarios about 
typhoon strike, and temperature and sea level change, 
etc. to assess climate risk. 


4.2.3 Key success factors 


Localisation — even though climate risk stress testing 
was initiated by global regulators and a set of stress test 
scenarios were defined, it is critical that the institution 
is able to adopt and apply the scenario in a way that 
suits the local situation and can be supported by 
regional data. This meant that an off-the-shelf solution 
developed in another part of the world would not have 
been suitable for this use case. The use of Regtech 
solution enabled localised subject matter expertise 
and guidance provided by the consultant to be fed into 
the technology solution ensuring it was applicable and 
compliant with the specific Hong Kong requirements. 


Maximisation of the use of internally/externally 
available data - the Regtech solution allowed 
utilisation of more than 20 external public information 
data sources, counterparties’ financial statements, and 
internally collected historical loss data. 


Targeted approach - the Regtech solution facilitated 
targeted analysis of the data allowing material risk 
identification and attribution analyses which then helped 
reduce the scope by focusing on certain portfolios (e.g. 
real estate loans) and determining the measures (e.g. 
loss given default and probability of default). 


Leveraging the existing models/stress testing 
framework to the largest extent - for example, 
adjusting the existing internal rating-based models for 
loss given default and probability of default by adding 
new variables and applying the new scenarios. 


The above two use cases illustrated how some banks 
are applying Regtech to facilitate Regulatory Reporting 
and Stress Testing functions. The banks approached 
data challenges with practical methods such as data 
ownership identification workshops, and paid attention to 
the localisation of the solution supported by regional data. 
The use of Regtech in these examples allowed the banks, 
in both cases, to improve the effectiveness and efficiency 
of the Regulatory Reporting and Stress Testing functions. 
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